home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20020314-20021006
/
000047_ishikawa@yk.rim.or.jp_Fri Apr 26 14:31:18 EDT 2002.msg
< prev
next >
Wrap
Text File
|
2002-10-06
|
11KB
|
288 lines
Article: 13338 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.rim.or.jp!news.rim.or.jp!not-for-mail
From: Ishikawa <ishikawa@yk.rim.or.jp>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: a bug on GNU/linux: speed reset to unintended value occasionally.
Date: Sat, 27 Apr 2002 02:34:56 +0900
Organization: Ye 'Ol Disorganized NNTPCache groupie
Lines: 264
Message-ID: <3CC98FC0.AADA5130@yk.rim.or.jp>
References: <3CAFF81C.8039CBF8@yk.rim.or.jp> <3CC6E9D7.F4F2C624@yk.rim.or.jp> <aa6sjh$1a9$1@watsol.cc.columbia.edu> <3CC84CA6.D49F85EC@yk.rim.or.jp> <aa9l3h$4s4$1@watsol.cc.columbia.edu>
NNTP-Posting-Host: pl1612.nas911.n-yokohama.nttpc.ne.jp
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-Trace: news.rim.or.jp 1019842500 38098 210.139.45.76 (26 Apr 2002 17:35:00 GMT)
X-Complaints-To: root@rim.or.jp
NNTP-Posting-Date: Fri, 26 Apr 2002 17:35:00 +0000 (UTC)
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
X-Accept-Language: ja, en
Cache-Post-Path: duron!unknown@localhost
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13338
Frank da Cruz wrote:
> : In any case, the inclusion of these capability into
> : KERMIT must have been deemed necessary upon popular demands,
> : and I hope you had a nice feedback from the users of KERMIT.
> :
> It comes from a conference we attended in Tokyo in 1987. We worked
> with people from NTT, DEC Japan, and KEK on this and it was widely
> used in Japan for some years.
I remember Fujii-san from KEK helped
the popularization of Kermit on Japanese PC.
Me, however, was probably in minority in that I was
attracted to Kermit because it had
a nice emulation of DG DASHER terminal.
The real mess caused by competing character code
standards are now handled by exisitng systems
in more or less satisfactory manner.
Many existing systems now come with their own
code conversion facilities. This is the only way
the systems would be viable in Japanese market.
> http://www.columbia.edu/kermit/papers.html
I found some papers there very interesting.
Especially the one comparing UUCP and Kermit.
(I supported UUCP at the office using stock Sun UUCP,
then TaylerUUCP for some years until we switched
over to IP-connection in 1994 or 1995.)
> Yes, this is the fate of all popular software. In fact, for a
> while, the icon for the Windows version of EMACS *was* a kitchen
> sink ;-)
Wow. This is probably a oft-asked question, but
I wonder why noone seems to have bothered to obtain
permission to use Kermit the frog for, say,
X-window icon for kermit? (If windows version of
Kermit uses such icon, I stand corrected. I don't use
kermit under windows, or for that matter Windoze unless
I am forced to...)
> I confess, it can be fun. It's like a laboratory in which we
> experiment with protocols and algorithms, and at the same time
> produce something useful that helps people in real life, and
> grows with them and with the times so those who like it don't
> have to leave it behind.
I hope you will find supporting Kermit fun.
Anyway, below is the result of
a little experiment I did to clear up
my understanding of some options, etc..
Hope some people might find this useful.
I got curious and
I measured the CPS rate reported on the screen
into 20% of the transfer of the binary file "wermit".
Four cases were considered.
The default case, case-1, is set as follows.
Other three sets add some control tweaks.
Case-2 was just to check that /binary and /transparnet was
a synonym.
The setting.
case-1: default setting + modification using a startup file
set modem type none
set line /dev/ttyS0 (on the receiving side ttyS1)
set speed 38400
set carrier-watch off
set flow rts
Transfer was done as
send /binary ./wermit ./wermit.tmp
case-2: `case-1' setting
+ /transparent in send command as in
Transfer was done as
send /binary /transparent ./wermit ./wermit.tmp
case-3: `case-1` setting
+ "set control unprefixed all"
Transfer was done as
send /binary ./wermit ./wermit.tmp
case-4: `case-1` setting
+ "set prefixing none"
(BTW, Completion doesn't show "none" as a valid third argument.)
Transfer was done as
send /binary ./wermit ./wermit.tmp
I measured CPS during a binary file transfer of
"wermit" itself with
profiled version of wermit (Compiled with gcc -pg ...original flags
...)
This is on linux, kernel 2.4.18. ("make linux" was used to re-create
the wermit binary after "-pg" was added to linuxa target.)
TABLE-1
CPS (measured into 20% of the transfer. The file is 2183313 bytes.)
============================================================================
CPS: case-1 case-2 case-3 case-4
---------------------------------------------------------------------------
send: 3010 3009 3835 3621
receive: 2973 2972 3786 3568
===========================================================================
>From TABLE-1,
Case-3 is the fastest on my PC.
As pointed out by Frank,
>from the measurement, it is obvious that
"/binary" only and "/binary" plus "/transparent" is equivalent for
binary file transfer by comparing case-1 and case-2.
My observation of subtle difference between
the CPS in case-3 and case-4 still seems to be valid.
(The numbers are more or less repeatable.)
I had no idea why. So I ran the profiled version of
wermit and below I append the top-10 functions found
in profiled data during the run.
Someone might be able to figure out if there
IS a reason for the subtle difference.
Again, thank you for the great software.
Appendix.
The profile data is as follows.
I show the top 10 functions on the receiving and
sending side. I am not entirely sure if gprof
is useful in this particular analysis, but
if someone is interested, I can send the
full output including the part that starts with
"Call graph (explanation follows)".
Case-3:
Here are the top-10 functions in case 3 (fastest):
Sending side:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
50.00 0.04 0.04 147 0.27 0.27 bgetpkt
25.00 0.06 0.02 150 0.13 0.17 spack
12.50 0.07 0.01 281 0.04 0.04 chk3
12.50 0.08 0.01 133 0.08 0.11 rpack
0.00 0.08 0.00 650 0.00 0.00 makestr
0.00 0.08 0.00 567 0.00 0.00 in_chk
0.00 0.08 0.00 411 0.00 0.00 ckstrcmp
0.00 0.08 0.00 321 0.00 0.00 conbgt
0.00 0.08 0.00 302 0.00 0.00 ckscreen
0.00 0.08 0.00 302 0.00 0.00 screenc
Receiving side.
Receiving side.
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
50.00 0.01 0.01 151 0.07 0.07 ttinl
50.00 0.02 0.01 16 0.62 0.62 docmd
0.00 0.02 0.00 13030 0.00 0.00 myfillbuf
0.00 0.02 0.00 13030 0.00 0.00 mygetbuf
0.00 0.02 0.00 653 0.00 0.00 makestr
0.00 0.02 0.00 475 0.00 0.00 ckstrcmp
0.00 0.02 0.00 327 0.00 0.00 conbgt
0.00 0.02 0.00 320 0.00 0.00 ckstrncpy
0.00 0.02 0.00 307 0.00 0.00 ckscreen
0.00 0.02 0.00 307 0.00 0.00 in_chk
Case-4:
Here are the top-10 functions in case 4 (slightly lower):
Sending side
(The presence of gtword could be attributed some
retyping of commands to the prompt. But I am not sure.)
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
63.64 0.07 0.07 150 0.47 0.47 bgetpkt
18.18 0.09 0.02 49 0.41 0.41 gtword
9.09 0.10 0.01 287 0.03 0.03 chk3
9.09 0.11 0.01 136 0.07 0.11 rpack
0.00 0.11 0.00 652 0.00 0.00 makestr
0.00 0.11 0.00 575 0.00 0.00 in_chk
0.00 0.11 0.00 494 0.00 0.00 ckstrcmp
0.00 0.11 0.00 316 0.00 0.00 conbgt
0.00 0.11 0.00 296 0.00 0.00 ckscreen
0.00 0.11 0.00 296 0.00 0.00 screenc
Receiving side:
(I think something is wrong in the 100.00 % count
in the first column...)
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
100.00 0.01 0.01 13317 0.00 0.00 myfillbuf
0.00 0.01 0.00 13317 0.00 0.00 mygetbuf
0.00 0.01 0.00 645 0.00 0.00 makestr
0.00 0.01 0.00 331 0.00 0.00 conbgt
0.00 0.01 0.00 323 0.00 0.00 ckstrcmp
0.00 0.01 0.00 313 0.00 0.00 ckscreen
0.00 0.01 0.00 313 0.00 0.00 in_chk
0.00 0.01 0.00 313 0.00 0.00 screenc
cf.
CASE-1: base line setting.
38400, 8N1 rts/cts,
no prefix tweaking.
no control tweaking.
send /binary
Output of
show comm, and
show control.
Communications Parameters:
Line: /dev/ttyS0, speed: 38400, mode: local, modem: none
Parity: none, stop-bits: (default) (8N1)
Duplex: full, flow: rts/cts, handshake: none
Carrier-watch: off, close-on-disconnect: off
Lockfile: /var/lock/LCK..0
Terminal bytesize: 8, escape character: 28 (^\)
Type SHOW MODEM to see modem-related items.
(/home/ishikawa/KERMIT/new-kermit/send/) C-Kermit>show control
control quote = 35, applied to (0 = unprefixed, 1 = prefixed):
0: 1 16: 1 128: 0 144: 1
1: 1 17: 1 129: 1 145: 1
2: 0 18: 0 130: 0 146: 0
3: 1 19: 1 131: 1 147: 1
4: 1 20: 0 132: 1 148: 0
5: 0 21: 1 133: 0 149: 1
6: 0 22: 0 134: 0 150: 0
7: 0 23: 0 135: 0 151: 0
8: 0 24: 1 136: 0 152: 0
9: 0 25: 1 137: 0 153: 0
10: 1 26: 1 138: 1 154: 1
11: 0 27: 0 139: 0 155: 0
12: 0 28: 1 140: 0 156: 1
13: 1 29: 1 141: 1 157: 1
14: 1 30: 1 142: 0 158: 1
15: 1 31: 0 127: 0 143: 0 159: 0 255: 1
(/home/ishikawa/KERMIT/new-kermit/send/) C-Kermit>